This bug is for using something like UUIDs/markers in the commit message of mach-try-perf try runs and having perfcompare use those to match the new/base revisions to each other.

The upcoming hg->git changes will have an impact on mach try perf by eventually removing the ability to get remote revisions locally (everything will be through lando). Also, new setups will no longer have access to the remote revision locally sooner than when support for it is completely removed. So this change will be needed soon.

Two main things will need to be done here:
(1) Add a UUID to the try run run commit messages.
(2) Have perfcompare match base, and new try runs based on this UUID.

For (1), it's relatively trivial to implement it mach-try-perf. Most of the work here will likely be on the perfcompare side.

Does it make sense for the second push to have UUID of both itself and the base revision? It might be nice to record that if we are adding this hashes to give us flexibility to automatically detect the corresponding base.

My understanding is that both pushes will have the same UUID, exactly for the purpose you're mentioning.
Is that not the case with this patch?

My thinking was if the non-base revision could have their own UUID so that tools could reference it. This would be helpful if you have multiple experiments with the same base revision

The patch that is currently up is for getting feedback at the moment. I agree with having two hashes though since we also do base-revision caching locally and we'll need a separate UUID for it in that situation.

https://hg.mozilla.org/mozilla-central/rev/b011a2f743c9